Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / binkommm.arc / BINKOMMM.TXT

Wrap

Text File | 1987-11-02 | 14.8 KB | 333 lines

NOTE: This was originally written for Opus. Any mention of Opus is interchangeable with BinkleyTerm. When Fido came out, Tom Jennings had this basic idea about mail that said that when the system runs mail, it ONLY runs mail, when humans can use the BBS, then ONLY humans can use the BBS. The two were always separate. In order to work this required the cooper- ation of all the people involved to make sure that they all agreed on the minimum time to run mail and what part of the day that would be, hence we have National Mail Hour. As mail load increased the idea was simply that National Mail Hour (also known as NMH) would just become National Mail 90 minutes, or whatever was necessary. The basic problem with this idea was that for systems that ran just a little mail, they had to block out human users for longer periods of times than what they wanted to, while those that handled a lot of mail never seemed able to get things done. Thom Henderson, President of Systems Enhancements Associates had a slightly different philosophy on how to handle a larger mail load. Instead of each board trying to take care of itself, mak- ing its own calls, we should have routing and Hosts and Hubs. The basic idea was that by having a few boards collecting all the mail, sending it to other boards that collected mail and then distribute whatever was coming into their Net, the overall load would be less. One board would forward its mail to a Hub, who forwards it along with all the other mail from boards under that Hub, to a Host, who forwards that along with the mail from other Hubs to another Host. Mail coming into a Host would be distributed to the Hubs who would distribute it to the individual boards. Along the main trunks, this is tremendously cost-effective. But further down the line there are problems. For example if you're connected to a Hub that is a long-distance call for you, you're generally expected to make that call every night just to check in and see if there's anything waiting after all the mail has come back down to the Hub level. Also mail is overall slower in distribution, and a few key boards have a tremendous load placed on them. There are also subtle problems, for example, your message can be read by every Sysop of every system along the way, and there are even programs that automatically copy your mail for later reading by the Sysop after its been forwarded. Another problem is that with Jennings idea you just lock out humans for longer times, while with Henderson's idea you still are locking out humans for longer periods, but now you're doing it in separate blocks which can be even more frustrating for people because once they finally get on the board, they only have a few minutes access. Another point here is that the only software that can automatically handle this set up costs $100 and is sold by Systems Enhance- ments Associates. Now along comes Wynn Wagner and OPUS. He has a very different idea about how to handle increasing mail loads. First off, we should notice that the most ANY computer bulletin board is ac- tually busy is about 80% of the time. Why not handle mail during that 20% free time? Largely the answer was, no one knows when that 20% will be. But consider this, if two boards are trying to send mail to each other, and if each board is busy 80% of the time, they're both free 20% of the time. Just the random chances of both systems being free at the same time will actually be 4% of the day, (20% of 20% is 4%), sounds like a pretty low chance right? Well, there are 1440 minutes in a day, so four percent of that is 57.6 minutes, a pretty substantial window. In order to use this window though, both boards have to be able to send or receive all the time so that whenever that 4% is, we're ready for it. The mail has to be all packaged and ready to go just in case. In order to be cost-effective though, we have to be able to re- strict when to place outbound calls to times when the phone rates are lowest. And there may be other considerations such as trying to call just after another board has picked up an echo, rather than just before. Or we might have a free outbound host that will forward mail, so we need to get our mail there just before that host makes their outbound calls so our messages don't sit on his board 24 hours waiting to go out. I hope you've noticed that we're talking about two distinctly different problems: 1: Always have all the mail ready to be forwarded. 2: Control when to make outbound calls. And in OPUS they're handled completely separately, OMMM.EXE bundles up mail making it ready to go out, and OPUS, using Z events in SCHED.BBS controls when to make the calls. That's been a very hard idea for some people to grasp in changing over from Fido or SEAdog to OPUS. In SEAdog especially, how mail was bundled was controlled by the same program that controlled when calls were to be made. OPUS uses two separate programs with separate controls. So let's examine that a little more. OMMM uses a control file and command line switches to tell it HOW to bundle mail whenever its run. It NEVER knows what time it is, it doesn't know anything about SCHED.BBS, it only knows about the control file and the command line. OPUS knows what time it is, and what is listed in SCHED.BBS and what is in the outbound mail directory, but it doesn't know anything about routing or why a particular file is in the outbound directory. Note: Matrix Messages that are entered with special flags such as Hold, Crash, or file-attach, will override OMMM's commands for only those messages. You can enter a Hold message, a Crash mes- sage and a normal message into your matrix message area for the same board and OMMM will handle each one differently. How should they be used together to get what you want? I'll show you my control file, schedule and batch files and try to explain why I'm doing things a certain way and hopefully you'll gain a greater insight into how to use OPUS 1.XX. Whenever a person enters a message in the matrix area, or in an echo area, or mail comes in (after tossing any echoes), I have OPUS exit after scanning for outbound echomail to my batch file where this section of the batch file is executed: ommm -hC:\opus\outbound -CC:\opus\misc\contfile.lst -sa -iopus100.prm -mc:\opus\msgs\email That is actually all one line, it just won't fit into the NOOSELETTER on a single line. Notice the '-sa' especially, it tells OMMM to use the commands starting at the line that says 'SCHED A' in the control file, (-CC:\opus\misc\contfile.lst) and ending with the next entry that has a 'SCHED' in it in the con- trol file. That section of the control file is: ; SCHED A ; onecm 119/13 129/26 119/30 119/4 119/14 124/111 ; onehold 161/34 120/5 114/14 12/1 109/612 119/42 onehold 383/0 138/41 114/15 17/43 161/1 ; arcdirect 119/13 101/301 arcdirect 107/511 ; archold 10/215 others ; What's going on here? Let's look this over section by section. onecm 119/13 119/30 119/4 119/14 124/111 129/26 I want send all the local mail as crash since they are all running OPUS and can handle the mail as soon as it comes in. Costs aren't going to be any trouble here as all the boards in Net 119 are in Chico. I don't always have mail for 124/111 or 129/26 but I want it to go out as soon as I have some for them. Primarily I'm sending out messages in specialized echoes that users don't have access to and that I get my mail to them is more important than the costs involved. onehold 161/34 120/5 114/14 12/1 109/612 119/42 onehold 383/0 138/41 114/15 17/43 161/1 The boards on the first line are boards I never call. They always call me (119/42 is the lone true Fido board in ChicoNet) to pick up mail, primarily I'm accumulating messages in echoes for them. The second line is a list of boards that I have to Poll at some time each day for echoes. So why am I putting their messages into HOLD archives? Because I accumulate mail for those boards 24 hours, but I don't want to call every time I get a new mes- sages for them, I really only want to place one call each day, and I especially want to avoid calling them during NMH. I'll get back to them later on when I set up to do the Poll. arcdirect 119/13 101/301 arcdirect 107/511 I have a problem with 119/13. It participates in an echo back east with 101/301. For some reason though he sometimes sends me his echomail as regular mail. Now I've got an arrangement to forward regular mail to a free outbound host on two conditions, first it has to be for a board inside the US, and second it can't be echomail. The Sysop of 119/13 doesn't believe it happens so I've set up my OMMM control file to automatically shoot mail for that board back to him. The mail for 107/511 is an echo, but for some reason that board wants to handle it only during NMH so I archive it together as regular mail. Archold 10/215 others 10/215 is my outbound host. He is willing to forward my outbound mail for free so long as it is for boards in the US and I don't load him down with echomail. He polls me every night before NMH to pick up anything that is waiting to go out. This schedule, SCHED A, is used almost every time I run OMMM. Even if I am going to run a different schedule I run this one first to set up the mail area. Once a day, at 8:00am I run the following schedule. Its purpose is to set up my long distance Polls for echomail SCHED C ; unhold 17/43 161/1 124/111 114/15 138/41 normcm 114/15 124/111 17/43 161/1 138/41 Poll 114/15 17/43 161/1 124/111 138/41 onecm 114/15 124/111 17/43 161/1 124/111 138/41 ; Again we'll go through this line-by-line. unhold 17/43 161/1 124/111 114/15 138/41 Almost all the commands in OMMM will only function on "normal" mail, mail in the outbound directory that has file extensions of and DOSEND. I'm using UNHOLD here to change the archives to "normal" so I can: normcm 114/15 124/111 17/43 161/1 138/41 Mark that mail as crash. But suppose I don't happen to have any mail waiting for one or more of these boards? Poll 114/15 17/43 161/1 124/111 138/41 onecm 114/15 124/111 17/43 161/1 124/111 138/41 I have OMMM generate a Poll message for each board, and I have ONECM change that to a crash message. Now for the odd part, why do I do this at 8:00am? At 8:00am I have OPUS change to Local-Only, telling it to only call boards that are free calls. So although I have all these message sitting there marked as Crash, OPUS won't make any out- bound calls for them until 10:00p.m. when the phone rates drop back down. I could run this at any time of the day, but the morning seems to be the time to have this happen without interfering with my human users, and the actual purpose I run the board is for the human users, so 8:00am is when I run this. I run one other OMMM schedule each day. This one runs 20 minutes before NMH and is to Poll one particular board at one particular time. SCHED F Poll 383/0 normcm 383/0 This is actually doing the same thing as SCHED C except that I'm only running it for one single board that I have a special ar- rangement with that I will call at this time and not earlier. Notice that I don't have the UNHOLD/ARCCM commands in the schedule. Actually I don't need it in SCHED C because once OPUS makes a connection with another board, it gives that board ALL the mail that is waiting for it, However there is an advantage to the way things are being done in SCHED C over this method. If the call goes through but we don't get a good connection I may not be able to get the mail that's waiting for me during this call, but I've "used up" my Poll and the outbound mail is still marked as HOLD. However in SCHED C where I've also marked the outbound mail as Crash OPUS would keep trying until it actually gets rid of everything that's waiting to go out. When this is run I have OPUS change to Mail-Only so it doesn't interfere with my human users. Notes: by Butch Walker This piece was originally written by Doug Boone to explain how to use OMMM with Opus. I have editied it to change to the Verbs used in OMMM 1.07. It is assumed that those reading this document already understand batch files used in operating bulletin boards specific to their software. It is also assumed that you have already read the docs with Binkley, and studied the sample Binkley.cfg. A couple of general comments. OMMM is a message bundler. It takes the messages cretaed by Opus/Fido/Seadog/TBBS/ etc, and bundles them into a Fidonet compatable packet or Arcmail file. The only way BinkleyTerm will send out mail is if OMMM has been run to create the bundles of mail for it to deliver. Think of BinkleyTerm as the mailman. Creating a message on your system is like writing a letter to someone. Until you put postage on it and drop it in the mail box it's not going anywhere. As far as BinkleyTerm is concerned, an outgoing message sitting in your mail area, hasn't been dropped in the mailbox. It doesn't recognize it. OMMM is the Post Office. It picks up the mail from your mail box, sorts it according to destination, and bundles it up based upon your directions. Once bundled it is ready for delivery, and never has to be unbundled or rebundled again. Just like a letter, once put in the mail box, you don't see it again. It's not in a black hole somewhere, just in the postal system waiting to be delivered to the mail box it's destined for. Just remember the only way mail is bundled with BinkleyTerm is to run OMMM. Be sure to modify your batch files accordingly. Also, BinkleyTerm does not unbundle mail. You need Arcmail From All to do that or Confmail Toss. Incoming Packets will go into your inbound file area. Confmail Toss will handle that just fine. Arcmail from requires those packets be in your directory that Arcmail resides. Last but not least, OMMM must reside in the same directory as BinkleyTerm AND OMMM and your Outbound area MUST be on the same drive. Doug Boone 119/5 119/0 (916) 893-9019 Edited by Butch Walker for OMMM 1.07 and BinkleyTerm 161/1 415-672-2504